1. Field of the Invention
This invention relates to systems and methods for computer storage. Particularly, this invention relates to systems and methods for dynamically determining and managing multiple volumes in a data backup system.
2. Description of the Related Art
Storage management systems are increasingly relying on exploiting storage subsystems and storage subsystem technologies to backup and restore data in a fast, non-intrusive manner. One example is found in the product suite of IBM Tivoli Data Protection For Hardware which utilize IBM Enterprise Storage Server (ESS) subsystems to create backups for databases and applications such as DB2, ORACLE and mySAP. A primary characteristic of this data is that it is typically managed outside of the context of the traditional storage management server, e.g., outside of the context of the TIVOLI storage manager server. In other words, the storage is generally not seen or controlled by the backup server.
One of the first tasks for a user of such a system is to describe the storage that is available from the storage subsystem for use by the local storage management client. For example, the user may have fifty logical unit numbers (LUN) which can be dedicated to the backup application and must be made known to the backup application. Another task for the user is to create a correspondence between a LUN which contains production data (i.e. a source LUN) and another similar LUN (e.g., identical in size and possibly other characteristics) that can contain the backup (i.e. a target LUN). These backups are usually the result of a hardware copy operation (e.g., FlashCopy) from a source LUN to a target LUN.
The original IBM TIVOLI data protection for hardware products introduced the concept of a FlashCopy target file (usually denoted as “.fct” file). The original .fct files were simple text files that comprised one or more pairs of ESS serial numbers. The first serial number in the pair represented a database/application source LUN and the second number represented a target LUN for a FlashCopy operation. When the backup application determined that application data was stored on a source LUN, it would search through the file for the entry which listed the source LUN serial number and chose the paired target LUN serial number as the recipient of the FlashCopy operation. This technique has several drawbacks.
For example, one drawback is that the user must have explicit knowledge (identifying number and size) of which source LUNs are being used by the database application. This means that the user would have to ask the database and/or storage administrator for a list of the LUNs currently being used by the database.
Another drawback is that the target LUN must be preassigned to backup host outside of the context of the backup application. The user would need to determine which host would be used for the backup operation and ensure that the target LUN were already preassigned to that host.
Furthermore, the source-target LUN pairs must be pre-matched by the user. The user would have to know the requirements for matching source-target LUN pairs based on the storage subsystem. For example, the particular IBM ESS subsystem being used requires that either the source and target LUNs be equal in size or the source and target LUNs must be controlled by the same logical control unit which was represented in part of the LUN serial number.
Also, the user must be explicitly aware when the list of source LUNs changes and any changes to the source LUN set must be reflected back in the file. An example of these requirements is that if a DB2 database grows and is using more source LUNs, the user must be aware that this happened and enter a source-target LUN pair for the new source LUN in the .fct file. In addition, conventional systems are also constrained because the source LUN can be associated with only one target LUN and the .fct file allows for only a single backup version to be managed.
One improvement was made to the .fct file when the data protection products began to allow and manage multiple backup copies and the concept of a data container was introduced. The data container was basically a way to group a set of source and target LUN pairs into a logical set. A source LUN serial number could appear in multiple data containers, each entry having a unique LUN pair. With this format, when the backup application would request a container which represented a set of LUN which could contain a backup. The backup application managed the usage of these data containers in such a way that a subsequent request for a data container would yield a different set of source and target LUN pairs which would describe a second copy of the backup data. Unfortunately, this system only addressed the problem of being limited to a single backup version.
In view of the foregoing, there is a need in the art for systems and methods for storage management where the user need not have explicit knowledge (identifying number and size) of the source LUNs. There is also a need in the art for such systems and methods where the target LUN need not be preassigned to backup host outside of the context of the backup application. Further, there is a need for such systems and methods where the source-target LUN pairs need not be pre-matched by the user. As detailed hereafter, these and other needs are met by embodiments of the present invention.